home *** CD-ROM | disk | FTP | other *** search
- dBASE Speed Tips
- (PC Magazine Vol 5 No 1 January 14,1986 Power User)
-
- These tips help shave off every possible microsecond from you
- dBASE command files. While some of the more general suggestions may
- contradict everything you've ever learned about writing dBASE programs,
- they cut the execution time for your programs to the bare minimum.
- Code-optimizing measures like these should not be used if program
- readibility is important. Your applications should be thoroughly
- debugged and tested before you implement the following procedures.
- With complicated programs, however, the cumulative effect these steps
- can have on the speed of operation is impressive.
- 1. Left justify everything: No indentations for IFs, DO CASESs
- or DO WHILEs.
- 2. All field, variable and filenames should use as few letters
- as possible.
- 3. Locate those field used in indexing, sorts or LOCATES at the
- top of your data files' structures.
- 4. Eliminate all comment lines (any line beginning with *).
- 5. Use commands such as SET TALK OFF and SET CONSOLE OFF when
- you don't need messages, preventing unnecessary use of the processor.
- 6. Trim line lengths by eliminating spaces wherever dBASE allows,
- e.g., turn DO WHILE K = 5 .AND. I = "MOM" into DO WHILE K=5.AND.I=
- "MOM".
- 7. Delete redundant statements such as a GO TOP after a USE
- <filename> command, a CLEAR GETS after ERASE, or LOOP as the last line
- of a DO WHILE routine.
- 8. Use capital letters as much as possible. Lowercase letters
- take a little longer to identify.
- 9. Take advantage of the fact that dBASE only reads the first
- four letters of a command. Never use APPEND where APPE will suffice.
-
- -----------------------------------------------------------------
- A Pseudocompiler for dBASE II
- (PC Magazine Vol 5 No 5 Mar 11, 1986 Power User)
-
- Too often, dBASE II command file writers are disappointed with
- the speed at which their lengthy programs run, especially with large
- data files. Many times, this degradation in speed occurs because of
- the way in which the application was programmed, not because of an
- increase in the number of records in the files.
- One good way to improve the speed at which a program executes is
- to limit the number of STORE and REPLACE commands used. dBASE must
- access your disk every time it encounters one of these commands.
- Therefore, changing your code from:
-
- STORE ' ' TO m:one
- STORE ' ' TO m:two
- STORE " " TO m:three
- REPLACE one WITH m:one
- REPLACE two WITH m:two
- REPLACE three WITH m:three
-
- to read:
-
- STORE ' ' TO m:one,m:two,m:three
- REPLACE one WITH m:one,two WITH m:two,three WITH m:three
-
- instead, will dramatically limit the number of disk accesses, speeding
- things up considerably.
- Because of dBASE's interpretive nature, such things as blank
- lines, comments (lines starting with *), and the indenting of program
- lines also slow a command file's execution times. However, eliminating
- all these items from your program may be more trouble than it's worth
- if you must later rewrite or debug your program.
- The "pseudocompiler" below, while not even close to a true
- compiler, will take your program and strip all blank and comment lines
- from it while left-justifying all code. It produces a second version
- of your code with a C on the end of the original name, which you can
- use in place or your original. Your original program is left intact
- for documentation, debugging, and other purposes.
- Editor's Note: This routine automatically adjusts your existing
- command files to take advantage of many of these tricks while leaving
- your original programs untouched. COMPILE.PRG is shown with indenta-
- tions, comment lines, etc. but you might want to run its code through
- itself to make it run faster. Be sure you have a data file called
- COMPILE.DBF (consisting of one character field 254 bytes in length)
- on your disk before running COMPILE.PRG.
- One word of caution: COMPILE.PRG strips away semicolons at the
- end of each line of code that is continued on the next line. Therefore,
- you should go through the "compiled" version of your code and replace
- the missing semicolon on any partial lines remaining in the program.
-
- * COMPILE.PRG
- * Requires COMPILE.DBF file that has one field called LINE which is
- * defined as character and is 254 characters in length.
- CLEAR
- SET COLON OFF
- SET TALK OFF
- SET ECHO OFF
- SET BELL OFF
- USE COMPILE
- COPY STRU TO TEMP
- USE TEMP
- ERASE
- STORE ' ' TO PROGNAME
- @ 10,20 SAY 'ENTER THE NAME OF THE PROGRAM TO BE COMPILED'
- @ 11,30 GET PROGNAME PICTURE '!!!!!!!!'
- @ 11,38 SAY '.PRG'
- READ
- STORE TRIM($(PROGNAME,1,7))+'C.PRG' TO M:PROG
- STORE TRIM(PROGNAME)+'.PRG' TO PROGNAME
- APPEND FROM &PROGNAME SDF
- GO TOP
- SET ALTERNATE TO &M:PROG
- SET ALTERNATE ON
- DO WHILE .NOT. EOF
- STORE 1 TO CNT
- DO WHILE ($(LINE,CHT,1)=' ' .AND. CNT<50) .OR. $(LINE,CNT,1) = CHR(9)
- STORE CNT+1 TO CNT
- ENDDO
- IF $(LINE,CNT,1) = '*' .OR. $(LINE,CNT,1) = ' '
- DELETE
- ELSE
- STORE TRIM($(LINE,CNT,254-CNT)) TO M:LINE
- ? M:LINE
- ENDIF
- SKIP
- ENDDO
- SET ALTERNATE OFF
- USE
- DELETE FILE TEMP
- QUIT
-
- -----------------------------------------------------------------
- More on dBASE III Function Keys
- (PC World February 1986 Star-Dot-Star)
-
- Another tip on setting dBASE III function keys ... This technique
- does not require changing the key definitions. When the WAIT TO
- statement is active, the function keys will return ASCII values 246
- through 255. The program DKEYDEMO.PRG below demonstrates how those
- key codes can be handled by a dBASE III application. The demonstration
- merely displays the name of the function key you press. An actual
- application would most likely execute a DO statement instead.
- A second unrelated technique involves eliminating the CASE
- statement entirely; instead, use the SET FUNCTION statement to define
- each key with "DO program-name;" (the semicolon will appear as the
- <Enter> key when the statement executes). Your menu progran can ACCEPT
- the user's response to a variable, then execute that variable using the
- dBASE III &variablename macro feature.
-
- DKEYDEMO.PRG:
-
- * This menu uses function keys without chaning their definitions.
- * When the WAIT TO statement is active the function keys return
- * ASCII values from 246 to 255. Since 255 is a null character it
- * must be handled differently than the others, as shown by the
- * last item in the CASE statement below.
-
- DO WHILE 1=1
- CLEAR
- * (Use @SAY statements to display a menu more quickly)
- TEXT
- ***** SAMPLE MENU *****
-
- [F1] Whatever
-
- [F2] etc.
- ENDTEXT
- WAIT ' Press a Function Key: ' TO action
- DO CASE
- CASE ASC(action) = 254
- ? "F2"
- CASE ASC(action) = 253
- ? "F3"
- CASE ASC(action) = 252
- ? "F4"
- CASE ASC(action) = 251
- ? "F5"
- CASE ASC(action) = 250
- ? "F6"
- CASE ASC(action) = 249
- ? "F7"
- CASE ASC(action) = 248
- ? "F8"
- CASE ASC(action) = 247
- ? "F9"
- CASE ASC(action) = 246
- ? "F10"
- CASE action = ''
- ? "F1"
- ENDCASE
- WAIT
- ENDDO
-
- -----------------------------------------------------------------
- dBASE Defect
- (PC World April 1986 Star-Dot-Star)
-
- dBASE III v1.1 has a problem that could result in the loss of
- significant amounts of data. When the SET CARRY ON condition is in
- effect and records are APPENDed to the end of a file, the image of the
- last record is copied into the appended record. If, however, the last
- record has its delete flag set on, the delete flag on the appended
- records will be set on as well. When the data base is PACKed, all the
- new records will be removed from the file because they are flagged for
- deletion. The problem also exists when you use the INSERT command but
- does not occur when you issue the APPEND FROM filename command.
- Ashton-Tate advises that you use the SET CARRY ON and APPEND
- commands with caution to avert potential data loss. One solution is
- to always issue the SET DELETE OFF command prior to writing new
- records to disk.
-